When I first saw GPT-5 in action, I sat back in my chair and felt a sense of powerlessness.
Watching it perfectly execute tasks that I thought only I should be able to do made me realize we are entering a new paradigm of intelligence.
그러나 실제 사용한 사람들은 5버전이 AGI가 아닌 퇴보에 가깝다고 비난을 했지만,
이제 제미나이 등의 발전을 보고 있다보니 이제는 어느정도 이해할 수 있을 것 같다.

- Stateful Conversation
Responses API 덕분에 모델이 이전 대화를 기억하고 이어가는 환경 내장
개발자가 전체 history를 매번 관리할 필요 없음
- Tool Orchestration 내장
웹 검색, 파일 조회, 계산 등 외부 도구 사용을 모델 내부에서 처리 가능
반복 루프와 상태 관리 코드는 API가 자동 처리
- 멀티모달 + 에이전틱 구조
텍스트, 이미지, 코드, 데이터까지 통합 처리
모델이 스스로 목표를 달성하도록 행동
*멀티턴 (Multi-turn) : 여러 번 주고받는 대화로 이전 질문과 답을 기억하고 연결하고 , 문맥 이해 기반 대화가 가능
샘 올트만의 발언은 단순 마케팅이 아니라, 구조적 변화를 반영한 선언이었다.
즉, GPT‑5 출시 이후부터는 개발자가 직접 에이전트를 설계하지 않아도, 모델이 “판단하고 행동하는 AI”,
다시 말해 AGI에 한발 더 가까운 형태로 활용될 수 있다는 의미였다.
2023~2024년까지의 API 구조는 기본적으로 stateless(상태값이 없음)였다.
개발자가 아닌 사람들은 모르겠지만, 실제 개발자는 매 요청마다 messages : []
전체를 다시 보내야 했고 이전 대화를 서버가 기억하지 않았고, tool 호출도 우리가 루프를 짜서 처리해야 했다
이 시기의 대표 API는 모두 상태 값을 보존하지 않았다(기억하지 않음)
- OpenAI의 Chat Completions
- Anthropic의 Claude Messages API
- Google의 초기 Gemini API
모델은 똑똑했지만, 에이전트는 아니었다.
각자의 개발자들이 , 대화를 이어나가는 것처럼 만들기 위해서
- 대화 상태 저장
- 토큰 관리
- tool 호출 후 재요청
- 오류 처리
- 반복 루프 설계
즉, “에이전틱 AI”를 만들려면 모델 위에 우리가 에이전트를 직접 구현해야 했다.

🚀 Responses API 공개 (2025년 3월) → 그러나 실제 제대로 사용가능한것은 GPT 5부터(2025년 8월)
OpenAI는 2025년 3월, Responses API를 공개했다.
이 API는 단순한 리네이밍이 아니었다.
previous_response_id 기반 상태 유지
서버 측 대화 관리
내장 tool 호출 통합
웹 검색 / 파일 검색 / 컴퓨터 사용 내장이제 개발자는 이전 응답 이어서 계속해
라고 요청할 수 있게 됐다.
이건 엄청난 변화였다.
🚀 GPT‑4o의 구조적 한계
한계 | 이유 |
|---|---|
상태 유지 어려움 | 모델 자체가 stateless, 모든 context를 개발자가 전달해야 함 |
tool orchestration 제한 | 외부 tool 호출과 반복 루프를 직접 구현해야 함 |
멀티턴 안정성 부족 | context window와 session 관리 기능 한계 |
에이전틱 AI 구현 난이도 | 모델 + 개발자가 만들어야 할 agent 로직이 많음 |
즉, GPT‑4o는 강력했지만 “에이전틱 AI 구현 환경”으로 쓰기에는 구조적 제약이 있었다.
반대로 GPT‑5 이후 구조는:
- stateful session 내장
- tool orchestration 통합
- multi-turn, multi-tool 안정성 확보
덕분에 개발자가 복잡한 agent를 구현하지 않아도, 모델이 스스로 판단하고 행동하는 환경을 만들 수 있게 된 것이다.
🔁 Gemini Interactions API (2025년 12월 베타)
Gemini API 위에 Interactions API를 베타로 공개했다.
여기서도 핵심은 같다:
- 멀티턴 상태 유지
- tool orchestration
- 세션 기반 흐름 관리
Google은 원래 Gemini에서 멀티턴은 지원했지만, 이걸 명확하게 agent형 API로 추상화한 건 2025년 12월이었다.
이 두 사건은 단순한 API 업데이트가 아니었다.
이건 “AI를 어떻게 호출하느냐”의 패러다임 전환이었다.
구분 | 2024년 이전 | 2025년 이후 |
|---|---|---|
상태 관리 | 개발자가 직접 | API가 일부 관리 |
tool 루프 | 직접 구현 | 내장 지원 |
에이전트 구현 | 복잡 | 간단 |
구조 | LLM 호출 | Agent 실행 |
이 시점부터 모델은 단순 “텍스트 생성기”가 아니라 상태를 유지하는 실행 엔진에 가까워졌다.
1. Stateless → Stateful 추상화
이전:
모델은 기억하지 않는다.
이후:
세션과 응답 ID 기반으로 흐름을 이어간다.
2. Tool이 “외부 기능”이 아니라 “내장 기능”이 됨
웹 검색, 파일 검색, 시스템 제어가 이제 모델 외부 확장이 아니라 API 구조 안으로 들어왔다.
이건 모델이 아니라 플랫폼이 에이전트화된 것이다.
3. LLM → Agent Runtime
2024년:
LLM + 우리가 만든 로직
2025년:
Agent Runtime + LLM
이 차이는 구조적으로 크다.
항목 | Anthropic Claude | OpenAI GPT‑5 + Responses API | Google Gemini + Interactions API |
|---|---|---|---|
상태 유지 | ❌ Stateless – 매 요청 전체 메시지 전달 필요 | ✅ Stateful – previous_response_id로 세션 유지 | ✅ Stateful – multi-turn, session 기반 |
tool orchestration | ❌ 직접 구현 필요, 호출 후 결과 전달 | ✅ 내장 – 웹/파일/계산 자동 | ✅ 내장 – API 내 도구 호출 통합 |
멀티턴 지원 | 가능하지만 개발자 직접 관리 | 내장 multi-turn, 안정적 | 내장 multi-turn, 안정적 |
토큰/비용 효율 | ❌ 대화 길수록 선형 증가, 컴팩팅 필요 | ✅ 이전 응답 ID만 전달 → 효율적 | ✅ 서버 관리 → 효율적 |
멀티에이전트 구현 | ❌ 개발자 책임, 반복 루프 직접 설계 | ✅ API 내장으로 간단 | ✅ API 내장으로 간단 |
compacting/최적화 | ✅ SDK/클라이언트 수준, 메시지 요약 | ✅ 필요 없음, API 상태 관리 | ✅ 필요 없음, API 상태 관리 |
개발자 부담 | 높음 – 상태, tool, multi-turn, 비용 최적화 모두 직접 | 낮음 – 목표/전략 설계만 | 낮음 – 목표/전략 설계만 |
에이전틱 AI 적합도 | 제한적 | 높음 – 내장 agent 환경 | 높음 – 내장 agent 환경 |
GPT‑5 이후 구조와 OpenAI Responses API, Google Gemini Interactions API 덕분에,
개발자는 단순 텍스트 생성기를 넘어 ‘실행 가능한 에이전트’를 설계할 수 있는 환경을 갖게 되었다.
이제 가능해진 것들을 정리하면 다음과 같다.
1. 멀티에이전트 에코시스템
여러 AI 에이전트를 동시에 배치하고 협업하게 할 수 있다.
예: 하나의 에이전트는 데이터 수집, 다른 에이전트는 분석, 또 다른 에이전트는 보고서 작성.
이전에는 각 에이전트별 반복 루프와 상태 관리 코드를 개발자가 구현해야 했지만, 지금은 모델과 API가 이를 자동으로 관리.
2. 자동화된 연구/분석 도구
모델이 웹 검색, 데이터베이스 조회, 코드 실행까지 수행하며 연속적인 분석 흐름을 생성 가능.
예: 시장 보고서 작성 → 경쟁사 동향 조사 → 시각화 자료 생성 → 보고서 초안 작성까지 모델 단독 실행 가능.
개발자는 단지 “목표와 전략”만 설계하면 됨.
3. 멀티모달 에이전틱 AI
텍스트, 이미지, 코드, 데이터 등 다양한 형식의 정보를 통합해 처리할 수 있다.
예: 디자인 콘셉트 생성 → 이미지 프로토타입 제작 → 피드백 반영 → 최종 산출물 생성까지 모델이 단일 세션 안에서 수행.
이전에는 각 미디어마다 별도 루프와 상태 관리 필요.
4. 개인화·컨텍스트 기반 에이전트
모델이 대화와 행동을 사용자별 컨텍스트에 맞게 유지.
예: 개인 비서, 고객 대응 AI, 학습 도우미 등.
이전에는 개발자가 매번 사용자의 모든 history를 관리해야 했지만, 지금은 세션과 previous_response_id로 자연스럽게 유지 가능.
5. 에이전틱 AI 플랫폼화
단일 모델이 아니라 모델 + API + tool orchestration = Agent Runtime 구조.
즉, AI 자체가 플랫폼이 되어 다양한 서비스를 구축 가능.
예: 기업 내 자동화된 업무 처리, AI 기반 프로젝트 관리, 멀티툴 통합 서비스 등.
덕분에 개발자는 이제:
반복 루프를 설계하지 않고도 상태와 툴 관리를 신경쓰지 않고도 모델을 자율적 판단과 행동이 가능한 에이전트로 활용할 수 있다.
즉, “에이전틱 AI” 시대가 본격적으로 열린 것이고, 실제 서비스와 플랫폼 수준의 AI 개발이 가능해진 것이다.